home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1988 / Jan 88 / re Multiple-Undos 1⁄21 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.7 KB  |  57 lines  |  [TEXT/GEOL]
  1. Item    1356186                         21-Jan-88        15:44
  2.  
  3. From:   ROSENSTEIN1                     Rosenstein, Larry
  4.  
  5. To:     MAGILL1                         Magill, Jon
  6.  
  7. cc:     MACAPP$                         MacApp Interest List
  8.  
  9. Sub:    re Multiple-Undos revisited
  10.  
  11. I recommend that people lookup the paper entitled "US&R: A New Framework for
  12. Redoing" by Jeffery Scott Vitter of Brown University.  It was published in IEEE
  13. Software in October 1984.  This describes a totally flexible scheme for
  14. handling undo.
  15.  
  16. He proposes something that no one has mentioned -- the ability to skip an
  17. operation that has been previously done.  For example, suppose you decided that
  18. the 3rd operation you did was wrong.  You could undo 3 times, skip once, and
  19. then redo twice to fix the problem.  (His proposal is event moe powerful than
  20. this; this is a very much simplified description of the paper.)
  21.  
  22. Implementing the ability to save multiple command objects and undoing or
  23. redoing them in the original order is not terribly difficult.  It requires
  24. extra space to store the command objects and the data they require.  (This can
  25. be significant; in DrawShapes, each shape would need 1 wasSelected bit per undo
  26. level you supported.  In MacPaint, each level of undo requires 50K.)  In this
  27. case, the UI is clear; you need an undo command that goes backwards and a
  28. separate redo command that goes forwards.
  29.  
  30. Allowing the user to skip around, however, is more complicated because some
  31. commands depend on one another.  For example, the user might: (1) create a
  32. shape, (2) changes its pattern, and (3) move it.  Clearly, (2) & (3) depend on
  33. (1) taking place, but are otherwise independent.
  34.  
  35. In the example given previously, the Undo Move command is only valid while the
  36. shapes involved are still around.  If the user deletes them, then undoing the
  37. move also has to undo the delete.  Keeping track of the dependencies could get
  38. complicated.
  39.  
  40. I think implementing an undo command for each tool would be confusing.  A
  41. possibility is to keep undo the way it is, but allow have each tool identify
  42. the last shape drawn with it, using a separate command.  That way the user can
  43. delete, move, ... this shape while still making use of the standard undo.
  44.  
  45. Using a hierarchical menu would solve the issue of adding many things to the
  46. Edit menu.  On the other hand, reprsenting the commands graphically might be
  47. the best of all.  That way you can represent the dependencies between commands.
  48.  
  49. The difference in these approaches is that a linear undo/redo simply brings the
  50. user back to a previous document state.  A non-linear approach allows the user
  51. to reach new document states by rearranging the operations.  The US&R paper
  52. talks about how the system resolved conflicts and ambiguities.
  53.  
  54. Larry
  55.  
  56.  
  57.